home *** CD-ROM | disk | FTP | other *** search
/ Complete Linux / Complete Linux.iso / docs / apps / database / postgres / postgre4.z / postgre4 / src / storage / lmgr / README < prev    next >
Encoding:
Text File  |  1992-08-27  |  4.4 KB  |  94 lines
  1. $Header: /private/postgres/src/storage/lmgr/RCS/README,v 1.2 1992/06/17 06:57:06 mer Exp $
  2.  
  3. This file is an attempt to save me (and future code maintainers) some
  4. time and a lot of headaches.  The existing lock manager code at the time
  5. of this writing (June 16 1992) can best be described as confusing.  The
  6. complexity seems inherent in lock manager functionality, but variable
  7. names chosen in the current implementation really confuse me everytime
  8. I have to track down a bug.  Also, what gets done where and by whom isn't
  9. always clear....
  10.  
  11. Starting with the data structures the lock manager relies upon...
  12.  
  13. (NOTE - these will undoubtedly change over time and it is likely
  14. that this file won't always be updated along with the structs.)
  15.  
  16. The lock manager's LOCK:
  17.  
  18. tag -
  19.     The key fields that are used for hashing locks in the shared memory
  20.     lock hash table.  This is kept as a separate struct to ensure that we
  21.     always zero out the correct number of bytes.  This is a problem as
  22.     part of the tag is an itempointer which is 6 bytes and causes 2
  23.     additional bytes to be added as padding.
  24.  
  25.     tag.relId -
  26.     Uniquely identifies the relation that the lock corresponds to.
  27.     
  28.     tag.dbId -
  29.     Uniquely identifies the database in which the relation lives.  If
  30.     this is a shared system relation (e.g. pg_user) the dbId should be
  31.     set to 0.
  32.  
  33.     tag.tupleId -
  34.     Uniquely identifies the block/page within the relation and the
  35.     tuple within the block.  If we are setting a table level lock
  36.     both the blockId and tupleId (in an item pointer this is called
  37.     the position) are set to invalid, if it is a page level lock the
  38.     blockId is valid, while the tuleId is still invalid.  Finally if
  39.     this is a tuple level lock (we currently never do this) then both
  40.     the blockId and tupleId are set to valid specifications.  This is
  41.     how we get the appearance of a multi-level lock table while using
  42.     only a single table (see Gray's paper on 2 phase locking if
  43.     you are puzzled about how multi-level lock tables work).
  44.  
  45. mask -
  46.     This field indicates what types of locks are currently held in the
  47.     given lock.  It is used (against the lock table's conflict table)
  48.     to determine if the new lock request will conflict with existing
  49.     lock types held.  Conficts are determined by bitwise AND operations
  50.     between the mask and the conflict table entry for the given lock type
  51.     to be set.  The current representation is that each bit (1 through 5)
  52.     is set when that lock type (WRITE, READ, WRITE INTENT, READ INTENT, EXTEND)
  53.     has been acquired for the lock.
  54.  
  55. waitProcs -
  56.     This is a shared memory queue of all process structures corresponding to
  57.     a backend that is waiting (sleeping) until another backend releases this
  58.     lock.  The process structure holds the information needed to determine
  59.     if it should be woken up when this lock is released.  If, for example,
  60.     we are releasing a read lock and the process is sleeping trying to acquire
  61.     a read lock then there is no point in waking it since the lock being
  62.     released isn't what caused it to sleep in the first place.  There will
  63.     be more on this below (when I get to releasing locks and waking sleeping
  64.     process routines).
  65.  
  66. nHolding -
  67.     Keeps a count of how many times this lock has been attempted to be
  68.     acquired.  The count includes attempts by processes which were put
  69.     to sleep due to conflicts.  It also counts the same backend twice
  70.     if, for example, a backend process first acquires a read and then
  71.     acquires a write.
  72.  
  73. holders -
  74.     Keeps a count of how many locks of each type have been attempted.  Only
  75.     elements 1 through MAX_LOCK_TYPES are used as they correspond to the lock
  76.     type defined constants (WRITE through EXTEND).  Summing the values of
  77.     holders should come out equal to nHolding.
  78.  
  79. nActive -
  80.     Keeps a count of how many times this lock has been succesfully acquired.
  81.     This count does not include attempts that were rejected due to conflicts,
  82.     but can count the same backend twice (e.g. a read then a write -- since
  83.     its the same transaction this won't cause a conflict)
  84.  
  85. activeHolders -
  86.     Keeps a count of how locks of each type are currently held.  Once again
  87.     only elements 1 through MAX_LOCK_TYPES are used (0 is not).  Also, like
  88.     holders, summing the values of activeHolders should total to the value
  89.     of nActive.
  90.  
  91.  
  92. This is all I had the stomach for right now..... I will get back to this
  93. someday.    -mer 17 June 1992 12:00 am
  94.